Quick initialization of data regions in a distributed storage system

ABSTRACT

A method includes integrating a file system recovery log layer in a file system. The file system buffers data in a cyclical manner, and transforms all incoming random requests into a series of synchronous sequential updates. The method determines a length value of a write transaction byte-range for a received write transaction. Upon the length value exceeding a threshold value, data for the write transaction byte-range is written to permanent storage in the file system. Upon the length value being less than the threshold value, the data for the write transaction byte-range is written to a recovery log that is stored in the file system recovery log layer. The threshold value is changed dynamically while the file system is mounted.

BACKGROUND

Numerous workloads, such as virtual machines (VMs), databases, andaccesses to user home directories, send small and synchronous writeoperations to storage. In addition, many small writes to a file systemactually translate into many more small writes to the storage layer toupdate the recovery log and various metadata structures. Storagecontrollers typically use non-volatile read and write memory (NVRAM) tobuffer these small writes and reduce their latency, but many systems,for example, systems based on a software-defined storage architecture,cannot install such expensive storage devices in every node. This is aparticular problem for spinning disk-only based systems because of theirpoor performance for such operations. While storing data on largenumbers of solid-state drives (SSDs) in every server can improve thesituation, it is very costly given the typical capacity requirements inmodern data centers. In addition, naively using SSDs to buffer randomwrites can severely degrade the lifetime of SSDs.

SUMMARY

One embodiment includes a method including integrating a file systemrecovery log layer in a file system. The file system buffers data in acyclical manner, and transforms all incoming random requests into aseries of synchronous sequential updates. The method determines a lengthvalue of a write transaction byte-range for a received writetransaction. Upon the length value exceeding a threshold value, data forthe write transaction byte-range is written to permanent storage in thefile system. Upon the length value being less than the threshold value,the data for the write transaction byte-range is written to a recoverylog that is stored in the file system recovery log layer. The thresholdvalue is changed dynamically while the file system is mounted.

These and other features, aspects and advantages of the embodiments willbecome understood with reference to the following description, appendedclaims and accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network architecture for quick initialization usingbuffering and replicating particular regions in parallel file systems,according to an embodiment;

FIG. 2 shows a representative hardware environment that may beassociated with the servers and/or clients of FIG. 1;

FIG. 3 illustrates a block diagram of an example server for quickinitialization using buffering and replicating particular regions in adistributed storage system, in accordance with an embodiment;

FIG. 4 illustrates an example high-level view of a distributed systemfor quick initialization using buffering and replicating particularregions for a distributed storage system, in accordance with anembodiment;

FIG. 5 illustrates an example quick initialization and buffer write dataprocess, in accordance with an embodiment;

FIG. 6 illustrates an example system layer traversal, in accordance withan embodiment; and

FIG. 7 is a block diagram showing a process for quick initializationusing buffering and replicating particular regions for a distributedstorage system, in accordance with an embodiment.

DETAILED DESCRIPTION

Embodiments relate to buffering and data replication and, in particular,quick initialization using buffering and replicating particular regionsin a distributed file system. Aspects of the embodiments are describedbelow with reference to flowchart illustrations and/or block diagrams ofmethods, apparatus (systems), and computer program products, accordingto the embodiments. It will be understood that each block of theflowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

FIG. 1 illustrates a network architecture 100, in accordance with oneembodiment. As shown in FIG. 1, a plurality of remote networks 102 areprovided, including a first remote network 104 and a second remotenetwork 106. A gateway 101 may be coupled between the remote networks102 and a proximate network 108. In the context of the present networkarchitecture 100, the networks 104, 106 may each take any formincluding, but not limited to, a LAN, a WAN, such as the Internet,public switched telephone network (PSTN), internal telephone network,etc.

In use, the gateway 101 serves as an entrance point from the remotenetworks 102 to the proximate network 108. As such, the gateway 101 mayfunction as a router, which is capable of directing a given packet ofdata that arrives at the gateway 101, and a switch, which furnishes theactual path in and out of the gateway 101 for a given packet.

Further included is at least one data server 114 coupled to theproximate network 108, which is accessible from the remote networks 102via the gateway 101. It should be noted that the data server(s) 114 mayinclude any type of computing device/groupware. Coupled to each dataserver 114 is a plurality of user devices 116. Such user devices 116 mayinclude a desktop computer, laptop computer, handheld computer, printer,and/or any other type of logic-containing device. It should be notedthat a user device 111 may also be directly coupled to any of thenetworks in some embodiments.

A peripheral 120 or series of peripherals 120, e.g., facsimile machines,printers, scanners, hard disk drives, networked and/or local storageunits or systems, etc., may be coupled to one or more of the networks104, 106, 108. It should be noted that databases and/or additionalcomponents may be utilized with, or integrated into, any type of networkelement coupled to the networks 104, 106, 108. In the context of thepresent description, a network element may refer to any component of anetwork.

According to some approaches, methods and systems described herein maybe implemented with and/or on virtual systems and/or systems, whichemulate one or more other systems, such as a UNIX system that emulatesan IBM z/OS environment, a UNIX system that virtually hosts a MICROSOFTWINDOWS environment, a MICROSOFT WINDOWS system that emulates an IBMz/OS environment, etc. This virtualization and/or emulation may beimplemented through the use of VMWARE software in some embodiments.

In other examples, one or more networks 104, 106, 108, may represent acluster of systems commonly referred to as a “cloud.” In cloudcomputing, shared resources, such as processing power, peripherals,software, data, servers, etc., are provided to any system in the cloudin an on-demand relationship, therefore allowing access and distributionof services across many computing systems. Cloud computing typicallyinvolves an Internet connection between the systems operating in thecloud, but other techniques of connecting the systems may also be used,as known in the art.

In one or more embodiments, the system 100 utilizes a process forbuffering and replicating data that has been added to a file system toimprove the small write performance of both application updates andinternal file system metadata updates by placing the data in NVRAM (suchas flash-backed dual in-line memory module (DIMMs) or SSDs) and thenreplicating the data on one or more servers (depending on reliabilityrequirements). One or more embodiments reduce the latency of each updatewhile not reducing the availability of the data under node failures. Inone example, after the data is hardened (i.e., placed in stable storageand, if required, replicated such to survive storage system failures),the file system gathers the data in memory into large chunks (ifcontiguous blocks are found) and flushes it to the storage layer. Oncedata has been flushed from memory to its permanent location, the datamay be cleared from NVRAM. In one embodiment, if upon a node failuredata exists in the NVRAM that has not yet been flushed to its permanentlocation, then a recovery sequence executes that flushes the data tostorage from one of the replicated copies in NVRAM. In one example, avirtual machine (VM) writing to storage was simulated by a benchmarkthat performed a random 8 KB write workload to a single 50 GB file. Withthe use of a 500 MB NVRAM, which is stored on consumer-grade SSDslocally and on a partner node for fault tolerance, the performanceincreases from ˜50 IOPS when writing directly to the spinning disks to˜3,000 IOPS when using one or more embodiments. Using more threads willsomewhat improve the performance to the disk subsystem, but the maximumthroughput of writing to a disk subsystem is very limited. When morethreads are used, the higher maximum write performance of SSDs may befully exploited. With the use of more NVRAM and/or a faster storagemedium, e.g., flash-backed DIMMs, the performance may be improved evenfurther. In one embodiment, because of the typically small size ofavailable non-volatile random-access memory (NVRAM) devices, only smallwrites are buffered. With SSDs the situation is somewhat different, muchlarger write sizes may be buffered but with lower performance gain. Inone example, the file system buffers the data in a cyclical manner,transforming all incoming random requests into a series of synchronoussequential updates to increase performance and reduce SSD degradation.

In one or more embodiments, the system 100 utilizes a process forcompressing, buffering and replicating zero regions in a distributedstorage system, e.g., a parallel file system, to resolve the “writeamplification” problem that otherwise occurs when writing to unallocatedblocks in a sparse file when the size of the write request is smallerthan the size of the file system block. One or more embodiments may beused with a process for improving the write performance of bothapplication updates and internal file system metadata updates by placingthe data in NVRAM (such as flash-backed DIMMs) or SSDs, and thenreplicating the data on one or more servers (depending on reliabilityrequirements). In one embodiment, once the write transaction data andthe zeroes (or other bit pattern) in the remaining parts of the filesystem block have been written to their permanent location in the filesystem, the write transaction data and the compressed data (whichtracked the zeroes that needed to be written the rest of the file systemblock) may be cleared from NVRAM. In one embodiment, if upon a nodefailure data exists in the NVRAM that has not yet been flushed to itspermanent location in the file system, then a recovery sequence executesthat flushes the write transaction data to primary storage, and writesthe required number of values (e.g., zeroes, etc.) or other bitpattern(s) to the rest of the file system block, from one of theavailable replicated copies.

FIG. 2 shows a representative hardware environment associated with auser device 116 and/or server 114 of FIG. 1, in accordance with oneembodiment. In one example, a hardware configuration includes aworkstation having a central processing unit 210, such as amicroprocessor, and a number of other units interconnected via a systembus 212. The workstation shown in FIG. 2 may include a Random AccessMemory (RAM) 214, Read Only Memory (ROM) 216, an I/O adapter 218 forconnecting peripheral devices, such as disk storage units 220 to the bus212, a user interface adapter 222 for connecting a keyboard 224, a mouse226, a speaker 228, a microphone 232, and/or other user interfacedevices, such as a touch screen, a digital camera (not shown), etc., tothe bus 212, communication adapter 234 for connecting the workstation toa communication network 235 (e.g., a data processing network) and adisplay adapter 236 for connecting the bus 212 to a display device 238.

In one example, the workstation may have resident thereon an operatingsystem, such as the MICROSOFT WINDOWS Operating System (OS), a MAC OS, aUNIX OS, etc. It will be appreciated that other examples may also beimplemented on platforms and operating systems other than thosementioned. Such other examples may include operating systems writtenusing JAVA, XML, C, and/or C++ language, or other programming languages,along with an object oriented programming methodology. Object orientedprogramming (OOP), which has become increasingly used to develop complexapplications, may also be used.

FIG. 3 shows an implementation of system 100 as a server 300 forcompressing, buffering and replicating all particular values (e.g.,zeroes, etc.) or other particular bit pattern(s) regions in adistributed file system. In one embodiment, the server 300 may be usedfor buffering and replicating data in a file system to improve the smallwrite performance of both application updates and internal file systemmetadata updates by placing the data in NVRAM or SSDs, and replicatingthe data on one or more servers (depending on reliability requirements).In one embodiment, server 300 comprises a storage module 310, a bufferpool module 320, a recovery log module 330, an optional threshold module340, a replication and buffering process 350 and a quick initializationprocess 360. In one embodiment, the quick initialization process 360 maybe used with or without a portion or all of the other modules.

In one embodiment, server 300 using the quick initialization process 360solves a write amplification problem that occurs when first writing to asparse file where the file system block is larger than the size of writerequests. In another embodiment, server 300 may also take advantage ofNVRAM in file system client nodes to reduce the latency of small andsynchronous writes using the replication and buffering process 350 thatscales write performance with the addition of file system client nodes,avoiding bottlenecks in small amount of NVRAM at the storage controller440 (FIG. 4) level.

In one embodiment, the targeted workloads for using the replication andbuffering process 350 include VMs, logging, etc. that includes smallsynchronous writes. Due to the size of the file system recovery log ofthe recovery log module 330 (which may be limited), in one embodimentbursts of small write requests are absorbed, and then are written backto system storage (e.g., network shared disk (NSD 425), redundant arrayof inexpensive disks (RAID) disk 450, FIG. 4) using the storage module310 in the background. In one example embodiment, if the amount of smallwrite requests remains excessive for a long period of time, the system(e.g., system 400) using the server 300 will enter a steady state wherewrite requests may need to wait for the recovery log of the recovery logmodule 330 to be wrapped before new write requests may be logged usingthe recovery log module 330.

In one embodiment, logging data in the recovery log of the recovery logmodule 330 improves the efficiency of write requests to the back endstorage system 400 (FIG. 4). In one embodiment, by logging writerequests using the recovery log module 330, the replication andbuffering process 350 allows small writes to be gathered into largerchunks in the buffer pool (virtual memory of the file system) of thebuffer pool module 320 before they are written back to the permanentstorage of the system 400 (FIG. 4). This is especially beneficial whenthe back end storage system 400 lacks any sort of NVRAM to buffer smallwrite requests. In one embodiment, when writing data having a byte-range(e.g., 0-255, -129-127, etc.) that has a size smaller than a full blockto an unallocated storage block, the file system must first write zeroes(or a pattern of bits) to the entire block (or the remaining regions ofthe file system block not in the write transaction) using the quickinitialization process 360. In one example, this means that a 4 K sizedwrite can turn into a 1 MB sized write, significantly increasing thelatency of small writes to the file system. In one embodiment, writelogging avoids this increased latency by logging the fact that the blockneeds to be zeroed out, allowing one of either two things to occur thatimprove performance. Either more writes occur to the block, avoiding theneed to zero out the block at all, or, if no more writes to this blockoccur, then the full block may be written out to permanent storage inthe background.

In one embodiment, once the zeroes (or pattern of bits) are written to apermanent storage location (e.g., NSDs 425, RAID disk 450, FIG. 4), thecompressed data may be cleared from the recovery log in NVRAM. In oneembodiment, upon a node failure, if data exists in the recovery log inNVRAM that has not yet been flushed to a permanent storage location,then a recovery sequence executes and flushes the data to permanentstorage from one of the replicated copies in the recovery log in NVRAMand writes the required number of zeroes (or other bit pattern) to therest of the file system block. In one or more embodiments, placing thefile system recovery log in NVRAM of client nodes (e.g., recovery logmodule 330 of server 300) improves performance (since many metadataoperations require updates to the recovery log). In one example, themaximum size of the recovery log is about 1 GB, whereas most NVRAM israther small (e.g., 500 MB). Therefore, if the optional threshold module340 (FIG. 3) is implemented, the write log threshold of the thresholdmodule 340 may be kept at rather small values, such as 4 K or 8 K. Inone embodiment, since there is only a single recovery log of therecovery log module 330, for each node (e.g., server 300) and filesystem, if there are too many applications having a burst of smallwrites, then the applications should be moved to use different filesystems or be placed on separate nodes, both of which use separaterecovery log regions.

FIG. 4 illustrates an example high-level view of a distributed system400 for quick initialization using buffering and replicating particularregions (e.g., zeroes or a particular known bit pattern) for adistributed storage system 400, in accordance with an embodiment. In oneexample embodiment, the system 400 includes multiple file system clients410 that each may implement server 300, an Internet protocol(IP)/interface (INF) switch 420, NSDs 425, storage area network (SAN)switch 430, storage controller 440 and RAID disk 450. It should be notedthat other components, number of components, etc. may be implemented insystem 400 without changing the scope of the one or more embodiments. Inone example embodiment, if NVRAM (e.g., recovery log module 330 ofserver 300) is used in the file system nodes (e.g., GPFS clients 410)exceeds the amount in the storage controller (440) (since it could beinstalled in every file system node), then write logging usingreplication and buffering process 350 assists in reducing latency. Inanother embodiment, if the NVRAM available on the file system nodes(e.g., GPFS clients 410) or on the network (in some other node or serveror appliance) has lower latency (from the perspective of theapplication) than the storage controller (440) then write logging usingreplication and buffering process 350 assists in reducing latency.

In one embodiment, the recovery log of the file system 410 is used forquick initialization to determine whether to flush a received writetransaction from the recovery log to a permanent storage (e.g., RAIDdisk 450) on a node in the system 400 based on whether the range for thefile system block is placed in the recovery log and if the receivedwrite transaction is a first write transaction to the file system block.In one embodiment, if it is determined to flush the received writetransaction and the received write transaction is the first writetransaction to the file system block, then the quick initializationprocess 360 (FIG. 3) appends data associated with the received writetransaction in the recovery log of the file system 410 and records thatremaining ranges of the file system block must be set to zeroes or aparticular known bit pattern. If required, data is replicated in anothernode in a distributed non-volatile layer and the range for the filesystem block is marked as committed.

In one embodiment, for a system with internal storage in each clientnode, if NVRAM is available either on a set of client nodes or in aseparate set of nodes, the use of quick initialization with or withoutwrite logging using one or more embodiments improves performance overthe direct use of internal magnetic disks of each client node. In oneembodiment, storage system with a fast write log such as RAIDcontroller, may be employed, but typically it is limited in the amountof NVRAM it supports. In one embodiment, if NVRAM can be placed in eachfile system client node, aggregate performance of all clients shouldincrease with each additional client node. For a storage system withseparate client and servers, the write path in this environment is verylong. For example, it takes two hops to hit the NVAM in the storagecontrollers, increasing the write latency. In one embodiment, placingNVRAM in the file system client nodes will decrease latency and increasethe scalability and performance of small writes.

In one example embodiment, the NVRAM configuration in file system clientnodes 410 may include flash-backed DIMMS, such as that which ships inthe IBM x-series M4 server, or SSDs installed on every file system node.In one embodiment, the file system client nodes 410 and the recovery log(e.g., of recovery log module 330, FIG. 3) are replicated (and possiblystriped) across the file system nodes, ensuring that each datum is ontwo different nodes. In one example embodiment, all recovery logs forthe entire system are stored on one or two (or more) fast flash-basedstorage system (which includes NVRAM inside of it). In another exampleembodiment, data is stored on disks, and metadata (which includes therecovery log) on SSDs.

In another embodiment, the recovery log is stored in a separate storagemedia from other file system metadata. In this embodiment, a“system.log” pool (the storage media on which the recovery logs arestored) is created and specified when the file system is created. In oneembodiment, once the system.log pool is created, the file systemrecovery log will automatically be placed in the system.log pool. In oneembodiment, the user may specify a different replication factor for thesystem.log pool, so recovery logs are stored with replication differentfrom other metadata in the “system” pool (the storage media on whichfile system metadata and/or data are stored).

In one example embodiment, the amount of NVRAM usable by the recoverylog on each file system client node 410 may be 128 MB or more, with arecommended size of 1 GB. In one embodiment, with replication, the sizeneeded for the recovery log is doubled. In one embodiment, the smallestamount that may be logged is dependent upon the granularity of filesystem dirty bits, which is the granularity that the file system cantrack and record updates to file system data blocks. In one example, fora VM workload that frequently requires 4 KB writes, it is necessary tomake sure bits can support this small amount.

In one embodiment, the recovery log of each file system (FS) (e.g.,global parallel file system (GPFS)) client 410 is placed on faststorage, such as NVRAM (e.g., flash backed DIMM), SSD, or PCIe SSD card.The fast storage can then be located, for example, in each FS client410, an SSD box connected to the storage controller 440, or on SSDs inthe storage controller 440. In one example, if the recovery log isstored on the file system client 410 nodes and requires protection fromnode failure, the recovery log is set to be replicated in fast storageof two or more client nodes. In one embodiment, if the optionalthreshold module 340 (FIG. 3) is implemented, the write log threshold isset to the largest write size to log (4 K or 32 K for example). In oneexample, at fsync time (which includes synchronous writes orasynchronous writes followed by an fsync call), the data is logged intothe recovery log of the file system client nodes 410 if the writes areless than a user specified threshold (if the optional threshold module340 (FIG. 3) is implemented). The log is forced (which means it isplaced on the physical storage device) to ensure that the data ishardened in the faster storage.

Data is never read out of the recovery log during normal operation(without any disk, node, or other hardware failures), but kept in thebuffer pool of the file system client 410 nodes, and written back topermanent storage at a later point in time by a writeback thread. In oneembodiment, performance can be improved by having the writeback threadswrite most of the data in the buffer pool to permanent storage beforethe need arises to remove records from the recovery log to make room fornew records. If the data is still in the buffer pool when the recordsneed to be removed from the recovery log, then the data must be firstflushed to permanent storage prior to the records being removed from therecovery log (which is performed by logwrap). Flush from buffer poolprior to cleaning records from recovery log ensures that incoming writeshave room in the recovery log to place data, and incoming writes willnot have to wait for space to be freed up. When writing the buffer (afile system block) out to permanent storage (writeback thread orlogwrap), all dirty ranges in a file system block are written out topermanent storage.

In one embodiment, when logwrap occurs, the replication and bufferingprocess 350 (FIG. 3) checks to determine, for a logged record, if thebuffer still is dirty. If the buffer is still dirty, which means that awriteback thread has not already written the data to permanent storage,then all dirty ranges for the buffer are written to permanent storage.In one example, if there are many write log records for a single filesystem block, then the first one will cause all dirty data (includingthe compressed zeroes or other bit pattern) for the file system block tobe written to permanent storage, and the following write log recordswill be removed from the recovery log of the file system client 410 nodewith no further data to be written out to permanent storage. If a nodefails, the file system 400 manager will run recovery, and write the datarecorded in the recovery log to permanent storage (e.g., RAID disk 450).

In one embodiment, when dirty data is flushed from the buffer pool ofthe file system client 410 to permanent storage, the sizes of the dirtyranges within the buffer are checked, for example, to see if they areless than the threshold if the optional threshold module 340 (FIG. 3) isimplemented. In one example, if any range is greater than the optionalthreshold, the buffer ranges are written out to permanent storage.Otherwise, each range is placed in the recovery log of the file systemclient 410. In one embodiment, if another file system client 410 nodeneeds to read the data that is dirty in another client's buffer pool,then the data will have to be flushed to permanent storage first (e.g.,NSD 425, RAID disk 450, etc.) so it may be read from the other filesystem client 410 node. This is to maintain POSIX file system semantics.Therefore, in one example embodiment, data is only logged if aFLUSH_FSYNC flag is set, which indicates that the dirty data in thebuffer pool is to be written to permanent storage for reasons other thanit is about to be read by another node.

Once a write transaction has been placed in the recovery log, before aresponse can be returned to the application to complete the transaction(if needed), the newly added records in the recovery log must be on theNVRAM device.

In one embodiment, once data has been logged, the dirty data in thebuffer pool will be written out to permanent storage (from the bufferpool of the file system client 410) by either logwrap or by a writebehind thread (based on a timer or some other mechanism).

If the data is not flushed to permanent storage via a writeback thread,then logwrap will write the data to permanent storage prior to removingthe records from the recovery log. This is the sub-optimal case, sincethis may mean that space in the recovery log of the file system client410 is limited and incoming write threads may need to wait on logwrapfor available space. In one embodiment, only the ranges logged arewritten out to permanent storage, since that is what is required beforethe log records may be removed from the recovery log of the file systemclient 410.

In one embodiment, if the optional threshold module 340 (FIG. 3) isimplemented, a writeDataLogThreshold configuration parameter is added tothe system 400. The writeDataLogThreshold specifies a value of thelength of a write transaction byte-range. If the length of the writetransaction is at or below this value, then the write transaction isplaced in the recovery log. If the length of the write transaction isgreater than the writeDataLogThreshold, then the data is not placed inthe recovery log and it is written to permanent storage. In oneembodiment, optional writeDataLogThreshold may be changed dynamicallyusing the optional threshold module 340 (FIG. 3) while a file system ofthe system 400 is mounted. In one example, if the value is reduced, thenlarger write requests simply stop being logged. If the value isincreased, then larger write requests will be logged. In anotherembodiment, the optional writeDataLogThreshold may be set per filesystem of the system 400. In one embodiment, if it is determined not toplace the range in the recovery log, and the byte-range to checkoverlaps with a byte-range for the file system block that has alreadybeen placed in the non-volatile layer, then the system 400 writes alldirty byte-ranges for the file system block to primary storage andplaces a marker in the non-volatile layer indicating that all previousupdates to the file system block are skipped upon recovery that occursupon node failure.

In one embodiment, to track which ranges have been logged, a new type ofdirty bit has been added referred to as “committed.” In one example, thecommitted bits track which ranges are in the recovery log, so that thesame range is not logged again and again. In one embodiment, when alogged range, which has not yet experienced logwrap, is re-dirtied, thecommitted bits for that range are reset so the range will be re-logged.

In one embodiment, the ranges to log are the ones that are dirty, notyet marked committed, and less than the write log size threshold. In oneembodiment, the ranges to log are determined by creating a new bit arraythat is the XOR of committed and dirty bits, and then AND with the dirtybits. In one example, any number of ranges in a single file system blockmay be logged at one time, as long as each one is less than the writelog threshold.

Conventionally, the updates to the dirty and committed bits aresynchronized by the fact that the caller has the file system block lockwhenever changing them (or the buffer they describe). In one embodiment,with write data logging, additional coordination is required withlogwrap to avoid corruption. In one example, while the read and writepath use the file system block lock to synchronize with each other,logwrap cannot grab this lock or risk deadlock. In one embodiment, flagsare created (used in a similar manner as mutexes) that do not conflictbetween a read and write path, but will conflict with logwrap.

The portable operating system interface (POSIX) standard does notspecify the state of uncommitted changes to a file after a crash. Forexample, consider a conventional file system with a 4 k block size.Consider an application performing three 256 k writes, A, B, and C, thatall overlap to some extent. Each write will dirty 64 pages, and somepages will be dirtied multiple times. The example conventional systemmakes no guarantees when and in which order these dirty pages arewritten back to permanent storage. Some of the pages might have beenflushed before the write B arrived, some of the pages containing B mighthave been flushed before write C arrived, and some arbitrary subset ofpages containing C might have been flushed before the machine crashed.As result, the file on permanent storage may have some arbitrarycombination of pages containing A, B, and C. This is different if theapplication calls fsync between writing A, B, and C. For example, iffsync after writing B completes successfully, and the machine thencrashes while writing C, one would expect that some of the pages towhich B was written might contain C instead of B, but none of themshould contain A instead of B.

In one example embodiment, consider the code decides to log A and C, butnot B. After writing A and an fsync, A will be in the recovery log offile system client 410, but not on permanent storage. In one example, Bis written, which “re-dirties” some buffers with data from B, and thesubsequent fsync now needs to flush data buffers containing B. If it isdecided not to log B and it is placed on permanent storage, it may beworrisome that if a failure occurs right after this second fsyncreturns, then log recovery will overwrite some of the new B's with oldA's, which would be incorrect if B is promised as stable according toPOSIX semantics.

To resolve this problem, before the file system replies to theapplication indicating that B has been successfully placed in permanentstorage, in one embodiment, a special record (a “done record”) is placedin the recovery log (and placed on NVRAM and possibly replicated) thatwill prevent log recovery from replaying the log records containing A.So, the file system may choose to either log B or flush the buffer topermanent storage and force (force means to place it on the actualstorage device) the done record. That solves a correctness problem forwrites that are too large to be logged, because it is always correct toflush without logging, provided the done record is forced. In oneembodiment, the case where the new write (B) does not overlap previouslylogged updates (A), it would be allowed to flush without forcing a donerecord.

FIG. 5 illustrates an example buffer write data process 500, inaccordance with an embodiment. In one embodiment, the process 500 startsat block 501. In one embodiment, in block 510 executing applications ina system (e.g., system 400, FIG. 4) write data into the file system. Inone embodiment, in block 511 the file system requests to Sync a filesystem (FS) block to the storage system, such as an NSD 425, RAID disk450, etc. (acquire lock on FS block buffer). In one embodiment, in block520 it is determined if the FLUSH_FSYNC flag is set. In one embodiment,if the FLUSH_FSYNC flag is set process 500 continues to block 530. If itis determined that the FLUSH_FSYNC flag is not set, process 500continues to block 525 where it is determined to not log data, and writethe data to the storage system. In one embodiment, after block 525,process 500 continues to block 550 and the process 500 ends.

In one embodiment, in block 530 process 500 finds all byte-ranges withina FS block that are dirty but not committed (using bit logic) thatsatisfy a predefined condition. In one embodiment, process 500 continuesto block 535 where it is determined whether uncommitted dirty rangesexist and satisfy the condition. In one embodiment, if it is determinedthat uncommitted dirty ranges do not exist and do not satisfy thecondition, process 500 continues to block 545 where data is not loggedand is written to permanent storage. After block 545 (and before block550), if byte-ranges overlap with a byte-range for the file system blockthat has already been placed in the non-volatile layer, then the systemwrites all dirty byte-ranges for the file system block to primarystorage and places a marker in the non-volatile layer indicating thatall previous updates to the file system block are skipped upon recoverythat occurs upon node failure. In one embodiment, process 500 proceedsto block 550 and process 500 ends.

In one embodiment, if it is determined that uncommitted dirty ranges doexist, process 500 continues to block 560. In one embodiment, in block560, if it is determined that the received write transaction is thefirst write transaction to the file system block, the process 500proceeds to invoke the quick initialization process 360 (FIG. 3) andproceeds to block 561. In one embodiment, in block 561 the process 500provides recording of the remaining ranges of the file system block setto zeroes or a particular bit pattern. In one embodiment, if it isdetermined that it was not the first write to the file system block orblock 561 has been completed, process 500 continues to block 536.

In one embodiment, in block 536 the process 500 reserves enough space inthe recovery log for all uncommitted dirty ranges. In one embodiment, inblock 537 process 500 acquires a mutex to synchronize with logwrap. Inone embodiment, in block 538 process 500 checks if ranges have changed(reduced due to logwrap). In one embodiment, in block 539 one or morerecords are created in the recovery log for each log range, trackingitems such as disk address, sector size, inode number, file offset, anddata size.

In one embodiment, in block 540 all dirty ranges are marked as‘committed.’ In one embodiment, in block 541 process 500 releases mutexto synchronize with logwrap. In block 542, all log records are writtenout to persistent storage of the file system. In one embodiment, process500 then proceeds to block 550 and ends.

In one embodiment, a special System.log pool is created in which tostore the file system recovery logs. In one example, inside of thispool, a log may be replicated. To store the log in the NVRAM of eachfile system client 410 (FIG. 4) node, logical volume is created of eachNVRAM and added to this pool. In one example, in this setup one of thecopies of the recovery log may not be stored on the local node. In oneembodiment, it takes approximately the same amount of time to replicatelog records on two remote nodes as one local node and one remote nodesince input/output (I/O) occurs in parallel.

One or more embodiments provide for: correct synchronization of buffereddata additions/deletions with an in-memory copy; correctly synchronizeI/O operations from any node in the cluster to logged data to avoid datacorruption and adhere to POSIX semantics; proper (POSIX) ordering ofmetadata and data buffering and recovery; fully parallel bufferingreplication, flushing, and removal of data; support a replication factorof 1 to N (N being a positive integer); tracking of fine grained datawrites and rewrites across user and kernel space (track data ranges thatare valid, dirty, and buffered (committed)); support selective writebuffering (e.g., size of a write threshold if the optional thresholdmodule 340 (FIG. 3) is implemented); and support for sparse files (avoidthe need to zero-out unwritten sections of a block while maintaining anoptional threshold).

FIG. 6 illustrates an example system layer traversal 600, in accordancewith an embodiment. In one example, the system layer traversal includesmultiple layers 630 where data traverses one way with the approximateone-way traversal times 611 at each layer. In the example, the totalround trip time is about 5 ms for 4 KB of data. In one example, theconventional/traditional FS system stores data at the traditional bufferlayer 620 into the FS log. In one embodiment, the data is stored atreference 610 using the FS recovery log in a FS 410 (FIG. 4) using aprocess, such as process 500, FIG. 5 or process 700, FIG. 7). As shown,the traditional layer 620 stores data at the storage controller layer621 at about 2 ms, whereas one embodiment stores data at the file systembuffer layer at about 50 μs.

FIG. 7 is a block diagram showing a process 700 for quick initializationusing buffering and replicating particular regions (e.g., zeroes or aparticular bit value or pattern) in a distributed file system, inaccordance with an embodiment. In one embodiment, in block 710, areceived write transaction is flushed from a first memory device (e.g.,an NVRAM, recovery log of a file system client 410, FIG. 4) to a secondmemory device (e.g., NSD 425, RAID disk 450, primary storage device,etc.) on a node in a file system (e.g., system 400) based on one or morebyte-ranges within a file system block. In one embodiment, in block 720it is determined if the received write transaction is a first writetransaction for writing data associated with the received writetransaction to the file system block. In one embodiment, in block 730 itis determined to flush the received write transaction to a recovery logthat is stored in a non-volatile storage layer of the file system. Inone embodiment, in block 740 if it is determined to flush the receivedwrite transaction to the recovery log and the received write transactionis the first write transaction for writing the data associated with thereceived write transaction to the file system block: then the methodincludes appending the data associated with the received writetransaction in the recovery log and recording byte-ranges remaining inthe file system block after writing the data associated with the writetransaction to the file system block, and recording an associatedparticular bit value or a particular bit pattern that the remainingbyte-ranges must be set to before the remaining byte-ranges are accessedor when a recovery sequence for recovering data in the recovery logexecutes due to a software or hardware failure. In one embodiment, inblock 750 the process replicates the data associated with the writetransaction as well as information regarding the remaining byte-rangesand the associated particular bit value or the particular bit patternthat must be set in another non-volatile storage layer of another nodeif required. In one embodiment, in block 760, the entire file systemblock byte-range as committed.

In one embodiment, process 700 may further determine to flush thereceived write transaction based on whether an application has requestedthe flush, a timer has expired, avoidance of data corruption or loss isrequired, or the data associated with the write transaction must be onthe secondary memory device to maintain POSIX semantics. In oneembodiment, process 700 may include determining if a byte-range is to beplaced in the recovery log based on whether the byte-range is notalready marked as committed and a particular policy is met, for example,to see if they are less than the threshold size (e.g., the threshold maybe dynamically set based on system/operator constraints, the thresholdmay be a predetermined size, etc.), dependent on available resources(e.g., recovery log memory available), etc.

In one embodiment, in process 700 the first memory device comprises avolatile memory device, and the second memory device comprises a primarystorage device on the node of the file system. In one embodiment,process 700 may further include that upon node or file system failure,quiescing file system and flushing data requests from the non-volatilestorage layer into the primary storage device and writing the associatedparticular bit value or the particular bit pattern to fill in thebyte-ranges of the file system block on the primary storage device asrecorded in the non-volatile storage layer, and then unquiescing thefile system to ensure proper POSIX semantics.

In one embodiment, process 700 may further include upon loss of accessto a copy of data and recorded byte-ranges and the associated particularbit value or the particular bit pattern in the non-volatile storagelayer that is on a different node than the node that is placing requestsin the recovery log, re-replicating data to ensure correct number ofcopies.

In one embodiment, process 700 may further include integrating a filesystem recovery log layer in the file system, wherein the file systemincludes a distributed non-volatile storage layer that buffers (stores)data committed to a stable storage on cluster nodes of the file system.In one embodiment, process 700 may further include flushing dirty andcommitted data to the primary storage device one of periodically or inresponse to a file system request, and marking the dirty data as nolonger dirty. In one embodiment, in response to memory or spacepressure, or a timer expiring, process 700 may traverse the recovery logand mark logged byte-ranges and byte-ranges with the associatedparticular bit value or the particular bit pattern as no longercommitted based on: determining if logged byte-ranges are still dirty;if the logged byte-ranges are still dirty, flushing data and writing theassociated particular bit value or the particular bit pattern to fill inthe byte-ranges of the file system block on the primary storage deviceas recorded in the distributed non-volatile storage layer to the primarystorage device; and marking the logged byte-ranges as no longer dirty.In one embodiment, process 700 may include removing byte-range records,bit value and bit pattern records from the recovery log.

In one embodiment, process 700 may include in response to a readtransaction for dirty data located on a file system node other than anode on which the dirty data is present, coordinating flushing the dirtydata to a primary storage device on the node with the dirty data priorto satisfying the read transaction.

As will be appreciated by one skilled in the art, aspects of theembodiments may be embodied as a system, method or computer programproduct. Accordingly, aspects of the embodiments may take the form of anentirely hardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,aspects of the embodiments may take the form of a computer programproduct embodied in one or more computer readable medium(s) havingcomputer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of theembodiments may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider).

Aspects of the embodiments are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments. In this regard, each block in the flowchart or blockdiagrams may represent a module, segment, or portion of instructions,which comprises one or more executable instructions for implementing thespecified logical function(s). In some alternative implementations, thefunctions noted in the block may occur out of the order noted in thefigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. It will also be noted that each block of the block diagramsand/or flowchart illustration, and combinations of blocks in the blockdiagrams and/or flowchart illustration, can be implemented by specialpurpose hardware-based systems that perform the specified functions oracts or carry out combinations of special purpose hardware and computerinstructions.

References in the claims to an element in the singular is not intendedto mean “one and only” unless explicitly so stated, but rather “one ormore.” All structural and functional equivalents to the elements of theabove-described exemplary embodiment that are currently known or latercome to be known to those of ordinary skill in the art are intended tobe encompassed by the present claims. No claim element herein is to beconstrued under the provisions of 35 U.S.C. section 112, sixthparagraph, unless the element is expressly recited using the phrase“means for” or “step for.”

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the embodiments.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the embodiments has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the embodiments in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the embodiments. Theembodiments were chosen and described in order to best explain theprinciples of the embodiments and the practical application, and toenable others of ordinary skill in the art to understand the variousembodiments with various modifications as are suited to the particularuse contemplated.

What is claimed is:
 1. A method comprising: integrating a file systemrecovery log layer in a file system, wherein the file system buffersdata in a cyclical manner, transforming all incoming random requestsinto a series of synchronous sequential updates; determining a lengthvalue of a write transaction byte-range for a received writetransaction; upon the length value exceeding a threshold value, writingdata for the write transaction byte-range to permanent storage in thefile system; upon the length value being less than the threshold value,writing the data for the write transaction byte-range to a recovery logthat is stored in the file system recovery log layer, wherein thethreshold value is changed dynamically while the file system is mounted.2. The method of claim 1, wherein the file system recovery log layercomprises a non-volatile storage layer of the file system.
 3. The methodof claim 2, further comprising: upon dynamically reducing the thresholdvalue, stopping logging the data for the write transaction byte-range tothe recovery log for byte-ranges length value exceeding the thresholdvalue.
 4. The method of claim 3, further comprising: upon dynamicallyincreasing the threshold value, logging the data for the writetransaction byte-range with byte-ranges length values being less thanthe threshold value in the recovery log.
 5. The method of claim 2,further comprising: upon determining not to place the data for the writetransaction byte-range in the recovery log, and the byte-range overlapswith a byte-range for a file system block that has already been placedin a non-volatile layer of the file system, writing all dirtybyte-ranges for the file system block to primary storage in the filesystem and placing a marker in the non-volatile layer indicating thatall previous updates to the file system block are skipped upon recoveryupon a node failure.
 6. The method of claim 5, further comprising:tracking byte-ranges that have been logged in the recovery log using acommitted bit, wherein committed bits track which byte-ranges are in therecovery log such that a same byte-range is not logged to the recoverylog again.
 7. The method of claim 6, wherein the byte ranges to log inthe recovery log are not yet marked using the committed bit and have alength value less than the threshold value.
 8. The method of claim 7,further comprising: creating a bit array that is an XOR of committedbits and dirty bits; and performing an AND process with the dirty bitsto determine the byte-ranges to log in the recovery log.
 9. A computerprogram product for quick initialization using storage and replication,the computer program product comprising a computer readable storagemedium having program code embodied therewith, the program codeexecutable by a processor to: integrate a file system recovery log layerin a file system, wherein the file system buffers data in a cyclicalmanner, and transforms all incoming random requests into a series ofsynchronous sequential updates; determine, by the processor, a lengthvalue of a write transaction byte-range for a received writetransaction; upon the length value exceeding a threshold value, write,by the processor, data for the write transaction byte-range to permanentstorage in the file system; upon the length value being less than thethreshold value, write, by the processor, the data for the writetransaction byte-range to a recovery log that is stored in the filesystem recovery log layer, wherein the threshold value is changeddynamically while the file system is mounted.
 10. The computer programproduct of claim 9, wherein the file system recovery log layer comprisesa non-volatile storage layer of the file system.
 11. The computerprogram product of claim 10, wherein the program code is furtherexecutable by the processor to: upon dynamically reducing the thresholdvalue, stop logging the data for the write transaction byte-range to therecovery log for byte-ranges length value exceeding the threshold value.12. The computer program product of claim 11, wherein the program codeis further executable by the processor to: upon dynamically increasingthe threshold value, log the data for the write transaction byte-rangewith byte-ranges length values being less than the threshold value inthe recovery log.
 13. The computer program product of claim 12, whereinthe program code is further executable by the processor to: upondetermining not to place the data for the write transaction byte-rangein the recovery log, and the byte-range overlaps with a byte-range for afile system block that has already been placed in a non-volatile layerof the file system, write all dirty byte-ranges for the file systemblock to primary storage in the file system and placing a marker in thenon-volatile layer indicating that all previous updates to the filesystem block are skipped upon recovery upon a node failure.
 14. Thecomputer program product of claim 13, wherein the program code isfurther executable by the processor to: track byte-ranges that have beenlogged in the recovery log using a committed bit, wherein committed bitstrack which byte-ranges are in the recovery log such that a samebyte-range is not logged to the recovery log again.
 15. The computerprogram product of claim 14, wherein the byte ranges to log in therecovery log are not yet marked using the committed bit and have alength value less than the threshold value.
 16. The computer programproduct of claim 15, wherein the program code is further executable bythe processor to: create a bit array that is an XOR of committed bitsand dirty bits; and perform an AND process with the dirty bits todetermine the byte-ranges to log in the recovery log.
 17. A systemcomprising: a file system including a primary storage device; and aclient node device coupled with a recovery log and a first memorydevice, the client node including a process that: integrates a filesystem recovery log layer in the file system, buffers data in a cyclicalmanner, and transforms all incoming random requests into a series ofsynchronous sequential updates; determines a length value of a writetransaction byte-range for a received write transaction; upon the lengthvalue exceeding a threshold value, write data for the write transactionbyte-range to permanent storage in the file system; upon the lengthvalue being less than the threshold value, write the data for the writetransaction byte-range to a recovery log that is stored in the filesystem recovery log layer, wherein the threshold value is changeddynamically while the file system is mounted.
 18. The system of claim17, wherein the process further: upon dynamically reducing the thresholdvalue, stops logging the data for the write transaction byte-range tothe recovery log for byte-ranges length value exceeding the thresholdvalue; and upon dynamically increasing the threshold value, logs thedata for the write transaction byte-range with byte-ranges length valuesbeing less than the threshold value in the recovery log, wherein thefile system recovery log layer comprises a non-volatile storage layer ofthe file system.
 19. The system of claim 18, wherein the processfurther: upon determining not to place the data for the writetransaction byte-range in the recovery log, and the byte-range overlapswith a byte-range for a file system block that has already been placedin a non-volatile layer of the file system, writes all dirty byte-rangesfor the file system block to primary storage in the file system andplacing a marker in the non-volatile layer indicating that all previousupdates to the file system block are skipped upon recovery upon a nodefailure; and tracks byte-ranges that have been logged in the recoverylog using a committed bit, wherein committed bits track whichbyte-ranges are in the recovery log such that a same byte-range is notlogged to the recovery log again; wherein the byte ranges to log in therecovery log are not yet marked using the committed bit and have alength value less than the threshold value.
 20. The system of claim 19,wherein the process further: creates a bit array that is an XOR ofcommitted bits and dirty bits; and performs an AND process with thedirty bits to determine the byte-ranges to log in the recovery log.